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Not too long ago, my wife and I decided to remodel the kitchen in our 
home and went to a firm specializing in this work. The salesman there 
is paid when he has made a sale, not for any suggested plans he draws 
up. So, after many months - my wife and I do not make remodeling 
decisions easily - he gave up on us. 


We started with another salesman, and it was 15 months before we 
indicated we were satisfied with his final proposal. He drew a final 
"picture" of the proposed job, a detailed schematic, added two straight 
lines under these drawings, and asked both my wife and me to sign, with 
these words: "That's exactly what you're going to get, for the cost 
we've agreed on, and the time of completion. If you want to make any 
changes, they will affect the cost and the time of completion." 


He made it clear that if we failed to sign, there would be no 
agreement. In short, he was prepared to see 15 months' effort go down 
the drain - because he knew from experience that if he did not get our 
Signed agreement, the potential problems could outweigh any benefits 
the job would bring. 


There is an analogy here to a dp professional, representing his 
department on an application development project, and an end user. The 
ap professional is the salesperson and the end user the customer. 

Note, however, what usually happens when the "salesman" asks the 
"customer" to sign on the dotted line; the end user refuses, for any 
number of reasons, including the simple fact that the end user sees no 
purpose to it and refuses to be tied down. 


The result is predictable. System designers need quantities of 
information that appear endless to the end user, who doesn't understand 
why such detail is required. Without advance agreement on the level of 
detail needed, dp people do not get the information they need; without 
such detail, the designer's system does not work as it should and the 
end user is dissatisfied. His propensity to make changes after a basic 
design is agreed on, without understanding why the changes should 
create any great difficulties, increases the potential for 
complications. 


A "signed and sealed" agreement could prevent much of this, but the dp 
representative finds it difficult to convince the user that such an 
agreement (and the considerable work for the user that it implies) is 
necessSary, and that it is reasonable for the dp professional to expect 
to have one. 
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I am convinced, on the basis of many years' experience with end users 
and dp professionals, that the dynamics described here are behind some 
of the most important criticisms of dp commonly held today by users and 
dp professionals alike; first, we in dp are able to implement only a 
small fraction of the aplications users want, and, second, when the 
aplications are implemented, they frequently do not meet users' needs, 
necessitating a great deal of rework and upheaval to the business while 
the reworking is being done and the resulting bugs are straightened 
out. The shortage of dp professionals is serious and is expected to 
remain so for years to come. This is a compelling reason to improve 
the quality of applications development so that end-user projects do 
not have to be redone, and dp time is used at maximum productivity 
levels. 


One IBM study suggests that improved dp and end user interaction can 
boost dp productivity by as much as 400%, getting the application up 
and running to the end user's specifications that much faster. So, 
while we are unqueStionably dealing with a shortage of trained people, 
it is equally evident that narrowing the communications gap between dp 
professional and end user can go far toward easing current backlogs. 


DP A MYSTERY TO USERS 


Basically, this communications gap goes back to the earliest days of 
the computer. Unfortunately, dp has been seen by end users aS a 
forbidding mass of difficult-to-understand technology, which could be 
made to serve their business needs solely through the efforts of a “new 
breed" of person, the dp professional, who waS somehow magically embued 
with all the requisite knowledge. Equally unfortunate, dp 
professionals themselves tended to believe this image. From one point 
of view, therefore, it might be said we're just dealing with the same 
old problem, but that would be a dangerous simplification - dangerous 
in tht it could keep dp and end user management from appreciating the 
true dimensions of the current problem, and the steps that must be 
taken to solve it. 


In the typical commercial establishment of 25 years ago, the person in 
charge of the computer operation was the financial officer, perhaps the 
controller. The dp manager reported to the controller. Whatever their 
backgrounds, they could achieve a meeting of minds without too much 
difficulty. The dp manager was running a set of well-defined 
applications, narrow in scope, applied to a narrow segment of the 
business. The company's customer, whether another business oganization 
or a consumer, had superficial contact with the new technology, perhaps 
only through an invoice or an accounts receivable statement. When 
Something went wrong, however embarrassing it may have been, it was 
easily resolved. 


Today, we are dealing with end users who rely on terminals to interact 
directly with customers; with end users who rely on the system to 
assure that their customers' requirements can be met; in short, end 
users rely on systems to Support people on the "firing line," those who 
are judged by the customers they gain or lose, or by customer 
complaints. 
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Now, when the end user's system doesn't function properly, the 
reverberations can be heard all the way up to the ceo's office. There 
is a great deal more. at stake, and if "blame" is to be apportioned 
there is plenty to go around for everyone. 


Let's start with some basic definitions. The end user is the person - 
actually the only person - who can perceive, or confirm, that a given 
application will lead to certain benefits which can be defined and 
usually measured. He, or she, alone can make ultimate decisions 
concerning a given application, because that person alone has the 
immediate responsibiity and the experience that can lead to sound 
judgments. 


By definition, therefore, the end user must have the critical role in 
the decision to invest in the application, in its design, and in its 
implementation. The dp manager is a purveyor of technology, supplying 
a service for the money the end user will pay. He, or she, should be a 
consultant on the most effective use of dp technology in helping final 
solutions to business problems and needs, and the governing authority 
on such matters as data security and system recoverability. The dp 
manager should never be the person to decide the next application to be 
implemented; making implementation decisions is the function of the 
ceo. To the extent that the dp manager does make implementation 
decisions, it is usually by default. 


In discussion after discussion we have found the issue is not what dp 


is all about, but what the business is about. The end user is not 
bothered by the cost of application development but by application 
effectiveness — the extent to which it delivers, or fails to deliver, 
the services that in turn impact customer relationships. The 
assumption, implied in the late 1950s, was that technicians "drove" the 
new dp technology. Today, that is not enough. Neither dp 
professionals nor the financial department "owns" end-user data; to the 
extent that both utilize it they are custodians. The "driver" today is 
the end user, and there can be no Satisfactory services without 
successful dp-end user relationships. 


SUCCESS STORIES CITED 


The proof of the basic fact can be seen in successful application 
development projects. Among the heaviest early dp users were insurance 
companies, and perhaps it's no accident they were among the earliest to 
adopt the project team approach to applications development, with heavy 
end user involvement. 


Until recently, even insurance companies with extensive dp experience 
shied away from "automating" group medical and dental claims handling. 
The data required is vast, each group contract written with an 
individual customer is separate and distinct, and the claims processing 
operation itself is complex. A medium-size insurance company based on 
the East Coast was among the first to break through the difficulties 
and develop a distributed claims processing application. The project 
leader was a headquarters claims manager, with working field 


experience; the majority of the project team members were actual claims 
administrators; a working relationship was established with the dp 
department that enabled this first-time, highly customer-sensitive 
application to be installed on time with a level of success that saw 
end users eager to cooperate in follow-on applications. 


An end user manager for a Southern newspaper utilizing an advanced 
computerized classified advertising system credits a good part of its 
success to his people's involvement in the system design. Testing an 
application system can take up to one-half of the dp organization's 
development resources, and a significant portion of that time is in 
redesign and retesting of user specs that were poorly communicated to 
begin with. Prevent the need for such rework, and you will make a 
Significant impact on total productivity. 


An end user coordinator in a manufacturing company found that so-called 
dp "overruns" were something quite different: they were actually the 
costs, in time and money, that resulted from the difference between the 
information the end user provided the dp department in the system 
proposal stage, and what the end user demanded of dp prior to 
considering the project complete. With a better understanding of dp 
requirements, and improved people interaction, the coordinator's end 
user systems did come in on time and within acceptable cost limits. 


Similarly, managers at a New England bank that had upwards of 65 new 
applications in development every year found that increased analysis 
time devoted to the design phase of a project before actual coding 
resulted in much less test time and signoff difficulties at the end, 
with project dates being met. More and more, bank end users and dp 
people are speaking the same language. 


Any number of additional examples could be cited. From long experience 
with both dp professionals and end users, I am absolutely convinced the 
most important single factor affecting applications development is how 
well the participants fulfill their roles. When dp managers are asked 
what problems they've experienced with development projects, they 
overwhelmingly (70% to 80%) respond: lack of proper user involvement. 
Statistics reveal the bulk of programmer/analyst time is spent on 
design, which is largely a matter of getting a good spec from the user 
- or, more importantly, getting it into test. "Test time" is largely 
redesign and recoding made necessary when user requirements are 
inadequately stated at the beginning of the project. 


WHO TO NARROW THE GAP 


The "bottom line" question is: what can be done to narrow the 
communications gap between dp professionals and end users? 


Dp professionals should view and treat end users as clients who want 
Services performed. They must focus on solving their client's real 
business problems. 
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Dp people should not discuss technical subjects with their 
user-clients. Most dp professionals simply take it for granted the end 
user must know about access methods, programming languages, operating 
systems, etc. Not true. The dp professional does not have to go 
beyond a few technical terms such as character, field, record, file, 
code, bug, debug. The end user wants to be told in basic English the 
same things any client must know: when the end product will be ready, 
its cost, quantity, and quality. In dp terms, quantity is capacity, 
i.e., the number of transactions in a given time frame, and quality 
concerns reliability and related factors. 


End users should understand their project development roles in terms 
that are meaningful to them. Dp professionals should be viewed by 
themselves and their users as project members, not as antagonists 
dealing in an arcane art, capable of solving all problems with a wave 
of the hand or seeking to ride roughshod over the end users’ 
operations. 


To help both dp professionals and end users understand their roles, I 
have found an excellent device is using the analogy of building a house 
- or remodeling a kitchen, which really did happen. The house analogy 
is essentially foolproof. End users grasp their roles instantly; they 
understand they must specify, in the required detail, just exactly how 
they want the house built and what they want it to contain. Similarly, 
dp professionals understand their roles in providing guidance, advising 
on the practicability of different approaches, and the various 
tradeoffs. 


Both groups understand it's only right and proper that a prospective 
home owner be required to Sign a contract with the builder before the 
house is built, and only right that any changes will entail reopening 
the contract. It's also only right that the builder be held to the 
promised completion date, built-in features, quality and cost. 


The house analogy works. End users and dp professionals understand it. 
It is successful in the effort to improve commununications between dp 
professionals and end user clients. 
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